The following excerpt from Request For Comment (RFC) 1112 describes the concepts underlying multicast routing.                [Internet Protocol] IP multicasting is the transmission of an IP datagram to a “host group”, a set of zero or more hosts identified by a single IP destination address. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time. A host need not be a member of a group to send datagrams to it. . . . Internetwork forwarding of IP multicast datagrams is handled by “multicast routers.”Deering, S., Introduction, pps. 1–2, “Host Extensions for IP Multicasting”, STD 5, RFC 1112, August 1989.        
The Internet Group Management Protocol (IGMP) is an Internet protocol that provides a way for host to report its multicast group membership to adjacent multicast routers. IGMP is formally documented by the Network Working Group of the Internet Engineering Task Force in RFC 2236, Fenner, W., “Internet Group Management Protocol,” Version 2, RFC 2236, November 1997.
Simply put, multicasting allows one computer on the Internet to send content to multiple other computers that have identified themselves as interested in receiving the originating computer's content. Multicasting can be used for such applications as updating the address books of mobile computer users in the field, sending out company newsletters to a distribution list, and “broadcasting” high-bandwidth programs of streaming media to an audience that has “tuned in” by setting up a multicast group membership. Other examples include using multicast routing for digital cable television to broadcast content such as Home Box Office (HBO) content to viewers tuned to HBO or Showtime to viewers tuned to Showtime, or for broadcasting a digital video conference to conference participants. The host group can include devices that reside on a local network, within a private network, or outside of the local network.
IP multicast routing includes the following components:                A layer-2 router that can forward IP multicast packets to and from other layer-2 or layer-3 routers, and to destination IP hosts in the host group;        A layer-3 router-to-router multicast routing protocol for forwarding the IP multicast packets between routers (for example, the Distance Vector Multicast Routing Protocol (DVMRP) or the Protocol Independent Multicast (PIM) protocol); and        A layer-2 host-to-router protocol for the IP host to communicate its multicast group membership to a router (for example, the IGMP protocol).        
There are three primary types of IGMP control packets transmitted between the routers and between the host and the routers: query, join, and leave. During operation, a router generates an IGMP query to the multicast group to see if the group is still in use. For example, in the digital cable television application of multicast traffic routing, the layer-3 multicast router that is forwarding the HBO content for the cable provider periodically sends an IGMP query control packet to the layer-2 router (i.e. the switch) which triggers the generation of multiple IGMP queries by the switch to all of the member hosts of a multicast group to determine whether the HBO group on that switch is still active. If not, then the digital cable provider need no longer send the HBO content to that switch. The IGMP join and leave packets are generated by the host. A host joins a multicast group by sending an IGMP join packet to the switch, which in turn forwards it to the multicast router. Likewise, a host leaves a multicast group by sending an IGMP leave packet to the switch, which in turn forwards it to the multicast router.
One of the drawbacks to supporting multicast routing is the high volume of traffic that can be generated when broadcasting the IP multicast data packets (e.g. the HBO content) to the members of host groups, especially since the IP multicast data packets are sent over the costly links between the layer-3 and layer-2 routers and switches. One way to control the high volume of IP multicast data packets is to perform the periodic querying described above in order to update the multicast group membership to insure that the IP multicast data packets are only sent where actually needed. However, the IGMP control packets (i.e. the queries, joins, and leaves) generated by the routers, hosts, and switches to update the multicast group membership can cause periodic flooding of the network. For example, if a layer-3 router sends an IGMP query to all of the member hosts of a multicast group that is very large, as in all of the hosts tuned into HBO, then the resulting responses (sometimes referred to as membership reports) from each of the hosts that must be forwarded back to the layer-3 router can cause a tremendous burst of IGMP traffic to the layer-2 switch and across the link to the layer-3 router. As the typical connection between the layer-2 switch and the hosts is an Ethernet connection having a bandwidth of only 10 Mbps, a relatively small pipe, the system may simply be unable to handle such bursts of IGMP traffic.
Another drawback to supporting multicast routing is that when the host joins a multicast group, the layer-2 switch broadcasts the IGMP join packet to all of the other local hosts and adjacent routers. Thus, security for the users is impaired, since the hosts will know what groups their neighboring hosts have joined. As an example, when a digital cable television viewer tunes into HBO, all other viewers will be aware of that fact by virtue of receiving the broadcasted IGMP join packet showing that host as the source.
Yet another shortcoming to supporting multicast routing is that when a host leaves the IP multicast group, forwarding the IGMP leave packet to the layer-3 router that is originating the content for the group doesn't reduce the IP multicast traffic unless all of the hosts in the group have left. As a result, forwarding the IGMP leave packet to the layer-3 multicast router may be unnecessarily generating additional IGMP control packets across the expensive link to that router. Another problem can arise when the host experiences some catastrophic failure, such as a power outage, that prevents it from communicating the IGMP leave to the switch and router. In that case, the layer-3 multicast router may be unnecessarily generating IP multicast data packets to hosts that do not need them.
What is needed, therefore, is a way to reduce the multicast traffic generated between the routers and the switch, as well as between the switch and the hosts, to optimize traffic flow and increase scalability. To provide such a reduction in multicast traffic without interfering with the operation of the underlying IGMP protocol presents a unique set of challenges requiring a new and novel solution.